Hello, as we learned countless time before: Visual feedback is the king! Especially when the GUI is as complex as the Train GUI.
It's finally here (Twinsen) The proposal was first mentioned more than 1 and a half years ago, in FFF-191. Since then, we kept mentioning it in our blog posts and players kept asking about it. After a lot of back and forth within the team on whether we should implement it or not, and how it should work, we finally have it almost finished for 0.17.
Hello, a large part of the team is attending GDS , if you are in Prague and interested in Games, you are welcome to come as well.
Taming the random generatorTwinsen One of the things in the large TODO list for 0.17 is giving a final polish to the map generator. There are quite a few obvious problems now in 0.16, and some less obvious ones. Here are some of the fixes and improvements (some work in progress): All combinations of settings should no longer create strange maps such as circles of cliffs. Much more predictable starting area resources that don't overlap each-other and are not covered by water. The resource generation settings now have a much more dramatic effect (previously they had little to no effect). Increased the number of steps (small, medium, big, etc) for each setting from 5 to 9 for even more customization. The starting area will always contain water, most often a lake close to the spawn position. Since the algorithm for generating ores was pretty much completely rewritten, there are many small improvements. Now for the less obvious problem: unpredictability. I saw quite a few people complain with vague comments like "the map generator sucks". So I often asked them what the problem is in detail. Some were complaining about the above problems, some did not understand what the settings do, and some had problems finding a "good map". I saw quite a few players click "regenerate" like crazy until they got a map with fat patches in the starting area, big oil patch and also uranium, complaining that it's too hard to find a "good map". Due to the randomness we seem to have set the expectation for "good map" a bit too high. Oil and uranium were never intended to be in the starting area, but due to the randomness of the generator they sometimes were there. Also sometimes maps were so wild that you would start off either swimming in resources or desperately looking for another iron patch. It would be simple to just say "that's just RNG, deal with it", but blaming poor game experience on RNG is just bad design. So what we did is: The starting area contains only iron, copper, coal and stone, in very predictable amounts. Uranium and oil are explicitly excluded from the starting area. Starting area resources are usually in one ore patch each (depending on settings). The starting area patches are usually close together. The starting area size setting no longer affects resource placement, it just has a fixed size. Outside the starting area, the regular algorithm "kicks in" so you can still get quite wild results, but they are far enough that it averages out. I believe this is a good balance where you can still have different experiences depending on your luck, but your starting experience is much more predictable and does not leave you with the feeling that you got screwed over by the map generator. We definitely don't want the map generator to be extremely flat and predictable. Opinions on the subject are quite wild too, with people having different expectations of what a good map should look like, so we try to only make changes based on actual problems. This might seem a bit controversial so we can add an option that disables this whole starting area logic, for purists. We plan some small tweaks coming to biters also (a tiny bit more biters close to the starting area), small tweaks to terrain, cliffs, water generation and possibly some new features to make the generated trees and decoratives look better. Most of these problems including the obvious and apparently simple ones were not that easy to solve. It's hard to make random generators do what you want, so TOGoS will explain what it took to actually get it done.
Mod portal features (Klonan) Sanqui has been quite effective these last weeks getting stuck in with the mod portal, so we have some interesting additions to talk about. Mod deprecation A modder can mark a mod as deprecated, which indicates they are no longer updating or maintaining it. The typical case is a mod will add something relevant for the current version of the game (E.G, a mod to scan the players starting area), and then an update to the base game makes the mod obsolete. Just deleting the mod could potentially cause problems for people playing an older version, people might ask what has happened to it etc. Marking as deprecated will keep the mod up on the portal, but it will be hidden from any public searches. This way people downloading using 'Sync mods with save' feature can keep playing, while new players won't stumble upon a mod that is no longer useful or up to date. It also preserves the downloads and discussions in case the author wants to revive it later. Collaborators It is often the case, that a mod author will want someone else to help them maintain and manage their mod, for instance if they are going on holiday when a major release is coming out. The way it has worked in the past, another modder would have to come and upload an updated version of the mod under their own name. Now a modder can set another player as a 'collaborator', which means they can help out will all the maintenance of the mod. Collaborators can do everything the author can do, except add or remove collaborators. You might also spot the other feature, transferring mod ownership. This lets the author give the mod completely to a collaborator, in the case that they are no longer interested in working on the mod at all. Discussions notice Mod authors can now display a notice above their mod page discussions, informing the users of any useful information. For example, an author might prefer you to report bugs on their GitHub page, so the notice will inform users of where they should go. An additional option allows the author to disable the discussions completely, in the case they have their own forum/thread somewhere for discussions. If you have any ideas for an improvement to the mod portal, please let us know on our Mod portal discussion subforum.
Status report (Twinsen) On Monday June 18th, we marked the last version of 0.16 as stable. There were no major problems, so now we are almost exclusively working on 0.17. Work on 0.17 is progressing well: Regarding the new campaign, we are already internally playing a rough version of the new player experience. We are still trying to figure out the exact and final style and concepts for the improved GUI, but we have some GUI windows implemented in game already, plus many base widgets. We use those to get a feel of what works and what doesn't. The new graphics back-end rewrite is nearing finalization. A closed-beta branch was sent to a few players to test that rendering works correctly across different hardware. The rendering is faster and no major issues were reported so far. But there is still much to do, such as improvements to VRAM usage and many experiments with shaders. Since from the graphics department Albert is working on the GUI and V453000 is working on the new campaign, only Ernestas is left working exclusively on the entity graphics. He is reworking some more entities for high-resolution, so expect some teasers in the future. There are of course other small projects that are ongoing, such as improved pipe-fluid physics and improved map generation, but more on those when they are fleshed out. Oh, and our coding always goes as planned without any problems.
Ok→Cancel versus Cancel→Ok (kovarex) A really strange debate started as a continuation of FFF-238. I insisted that the button order should obviously always be OK Cancel, as in any UI I see around. But little I knew, that this is actually specific to windows, and on Linux or macOS, the order is reversed: Eventually, we figured out, that we are not the first one trying to solve the problem. The solution we are now experimenting it sounds like a bad idea: "Make it so much different and Factorio specific, that the way it is done in your specific system will not interfere with your muscle memory". Which brings me to the load game dialog mockup:
New player experience (V453000 & Abregado) In the last several weeks/months we have been working on deciding the fate of the campaign and the demo/tutorial missions. Hi, I'm Ben (Abregado). My experience as an educator using Factorio in the classroom means I have thoroughly examined new players (young and old), and have played the first 30 minutes of Factorio for as many hours as some players spend on a single megabase. The systems in Factorio are deep and interconnected, so creating an onboarding experience for a single concept poses many exciting challenges. We find that the Freeplay portion of the game is already enjoyable to its target audience, but those who prefer a more guided experience only get a short campaign which doesn’t even utilize all of the features we’ve added to the game. On top of that brand new players need to dig through a tutorial which takes about 30-45 minutes to get to automation, which is what the game is about. We want to keep the demo so that anybody who wants to try the game can do it for free, and get a proper representative introduction to what Factorio is. For Factorio, the demo should serve a dual purpose of a tutorial and a teaser, both of which we feel could be improved... Currently we find the demo has the following problems: The impact of the first level isn’t very visually representative of what Factorio is. Gives the impression of being a Minecraft clone in the first tutorial mission by having to mine manually and do hand crafting. Key concepts like Assembling machines and electricity are not presented for the first two levels. Player actions are so heavily constrained that the player learns just how to solve the tutorial rather than learning the concepts we are trying to demonstrate. Each of the levels is disconnected from the previous. Which item recipes are available, that there are suddenly built structures and the location is completely different. Grindy tasks like obtaining X resources in 2nd tutorial mission don’t have any clear purpose. The player does it because they are being told to, not to achieve some other goal that would make sense in the progression. A lot of information is not important and just floods the player with noise, for example many of the messages. The places where the player gets information are scattered - Objective window in the top left, the player character talking to themselves in the console chat and the yellow "TAB bubbles". The three different information channels competing for attention. In this case also two of them telling you the same self-explanatory information (where is the current objective shown, if you didn’t get it), while the chat informs you that your character is alive. A typical objective without purpose. (I guess the game will tell me what is it for soon?) Doesn’t this message resemble another game? What we would like to achieve with the new design: Create an immediately gripping environment that better sets up the Factorio feel. Showing and teaching core concepts like Assembling machines and electricity in the first level using as little complexity as possible. Providing goals through the technology tree, working with laboratories and the technology GUI as soon as possible. Standardize the way players obtain new items. Every recipe has to be obtained through a technology - that way the player triggers recipe progression and gets them as a reward. Starting a new level should start the player at a similar progression state where the previous mission left off. Teaching by experimentation instead of jumping through arbitrary tasks. Letting the player coming up with their own solution of a puzzle. Unify the channels the player gets information from (mostly GUI improvements). After finishing the demo, the player should be ready to continue by playing the main campaign, or jump straight to the Freeplay. If you had to pick one entity that represents the game to you the most, which one would it be?
AMD Ryzen crashes (Klonan) The long fight with the elusive Ryzen bug (more and more) seems to finally have some resolution. A few weeks ago I sent an email to AMD, filling them in on the details of the crash, and asked them if they could help us solve this. Very quickly I was put in touch with a member of their CPU engineering team, and they got to work with their investigation. After a few days, and after providing them all the information we have (log files, source code, crash dumps etc.), the cause of the issue was identified. Some other developers in the industry also had this problem and worked with AMD to fix it, so it's unlikely that the CPU bug was fixed only because of us, but we are honoured to have contributed to this. Unfortunately we do not have any technical or deep insight into where exactly the problem lay, or what the fix was, as it was somewhere between the motherboard BIOS and the Ryzen chipset drivers. So if you are running Factorio on a Ryzen system, we advise you to update your BIOS using the files and procedures found on your motherboard manufacturer's website, and update your chipset drivers to the latest version.
Hello, it has been extremely cold these last weeks. It's one of those weeks when we can't think of anything to write about. So we will try to write some small parts.
